…API 31+)

RetroArch Android collapsed both libretro rumble channels (RETRO_RUMBLE_STRONG
and RETRO_RUMBLE_WEAK) into a single vibration output by OR-merging their
amplitudes before calling InputDevice.getVibrator(). This made the strong
(large/low-frequency) and weak (small/high-frequency) motors feel identical —
rendering motor separation in cores like SwanStation completely ineffective.

Fixes libretro/swanstation#72.

Changes
-------

android_joypad.c:
- Remove the OR-merge of strong | weak into new_strength. Each channel is now
  updated independently and held in the existing last_strength_strong /
  last_strength_weak per-port state.
- Add a new JNI call path to doVibrateJoypad when the method is registered and
  id >= 0 (controller, not device vibration). Both normalized amplitudes are
  passed separately so the Java side can route them to individual motors.
- Preserve the original OR-merge behavior as the legacy fallback for the device
  vibration path (id == -1) and for builds where doVibrateJoypad is unavailable.

RetroActivityCommon.java:
- Add doVibrateJoypad(int id, int strongStrength, int weakStrength, int unused),
  the new JNI entry point for per-channel controller rumble.
- On Android 12+ (API 31), doVibrateJoypadApi31() uses
  InputDevice.getVibratorManager() to enumerate the controller's vibrator IDs
  and drives them independently via CombinedVibration.startParallel(). Index 0
  is mapped to the strong (large/low-freq) motor and index 1 to the weak
  (small/high-freq) motor. This ordering is consistent across tested controllers
  but is not guaranteed by the Android API; the code degrades gracefully.
- If the controller exposes only one vibrator, max(strong, weak) is used so the
  device still rumbles.
- If VibratorManager returns no vibrator IDs, or on Android < 12, falls back to
  the existing doVibrate() single-vibrator path.
- The existing doVibrate() method and the "Enable Device Vibration" path are
  completely unchanged.

platform_unix.h / platform_unix.c:
- Register doVibrateJoypad as a new jmethodID alongside doVibrate.
  GET_METHOD_ID clears exceptions on lookup failure, so doVibrateJoypad is NULL
  on older APKs and the C-side fallback fires automatically.

build.gradle:
- Bump compileSdkVersion from 30 to 31. Required to reference VibratorManager
  and CombinedVibration at compile time. minSdkVersion is unchanged (API 16).

Tested
------

Confirmed strong and weak motors are now driven independently on Android 14+:
- Sony DualShock 4 (Bluetooth)
- Sony DualSense (Bluetooth)
- 8BitDo Pro 2 in Xbox One mode (Bluetooth)

Verified in SwanStation running Metal Gear Solid (PS1): weak-only rumble events
(e.g. distant explosions) are now perceptibly lighter than strong-only events
(e.g. alert state), which were previously indistinguishable.

Fallback behavior confirmed unaffected: controllers on Android < 12 still
rumble via the legacy single-vibrator path, and "Enable Device Vibration"
continues to function as before.